REMARKS 



Claims 20, 21, 53, 65 and 71 have been amended to correct a typographical error. 
No claims have been added or cancelled. Claims 1-71 remain pending in the application. 
Reconsideration is respectfully requested in light of the following remarks. 

Section 102(e) Rejection : 

The Office Action rejected claims 1-11, 14, 17, 22-32, 35, 38, 41-49, 52, 54-64 
and 64 under 35 U.S.C. § 102(e) as being anticipated by Teodosiu et al. (U.S. Publication 
2002/0062375) (hereinafter "Teodosiu"). Applicants respectfully traverse this rejection 
for at least the following reasons. 

Regarding claim 1, contrary to the Examiner's assertion, Teodosiu fails to 
disclose a resolver node, wherein the resolver node receives a query message from one of 
the plurality of peer nodes , determines a particular instance of the resource on a particular 
one of the one or more peer nodes , and forwards the query message to the determined 
resource instance . Instead, Teodosiu discloses a Resource Naming Service (RNS) server 
that receives a request for a resource from a peer, attempts to determine a location or 
locations for the resource and, if a location or locations are found, returns the location(s) 
to the requesting peer, which then is responsible for accessing the resource at (one of the) 
returned location(s). This is clearly disclosed in Teodosiu for FIG. 1 in paragraphs 
[0036] and [0037]: 

[0036] In general, [a peer] accessing a resource is a two step process. First, 
the resource must be located using the locator service. Second, the 
resource is actually accessed at the location or set of locations returned by 
the locator service. 

[0037] For a peer 140 within realm 150, the first step in accessing a peer 
resource involves communicating with the peer's assigned home RNS 
server 130. The home RNS server 130 , possibly in cooperation with 
registrar 110 and another RNS server 130, determines one or more 
locations within realm 150 where the resource is expected to be available . 
In one embodiment, the set of locations returned by the home RNS server 
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130 to the requesting peer 140 may depend on the current network identity 
(in particular, the current IP address or IP addresses) of peer 140, on the 
current traffic load on the realm, as well as on other parameters that are 
known to the RNS servers 130. It is up to the peer 140 to take the second 
step to actually access the resource at the provided location(s) . 

Specifically, Teodosiu does not teach that the RNS server forwards the query 
message to the determined resource instance . Instead, Teodosiu teaches that the RNS 
returns location(s) for a requested resource to the requesting peer, which is then 
responsible for accessing the resource at the provided location(s). 

Applicants note that the Examiner cites FIG. 4, ref. 440 and paragraph [0081] in 
regards to the limitation in claim 1 forward the query message to the determined resource 
instance . Note that in paragraph [0079], ref. 440 of FIG. 4 is described: 

[0079] If the locator service is known, the request is directed in 440 as 
resource locator traffic 310 to the home RNS server 130 to which the peer 
140 has been homed during the registration process , as described earlier. 
The home RNS server 130 then follows the steps earlier described in FIG. 
2 to locate content published under its realm, or to contact the remote 
locator service to locate a remote peer resource. 

Thus, ref. 440 of FIG. 4 indicates that the request is directed to the home RNS 
server , and does not indicate that the request is forwarded to the determined resource 
instance . Further, it is only after the RNS server receives the request that the requested 
resource is located by the RNS server. In paragraph [0081], the peer (platform 370) 
waits... for a response from its home RNS server. If one or more locations are received, 
platform 370 selects one or more locations to try in 460. The request is then forwarded as 
peer-to-peer traffic 320 directly to the selected location or locations in 425 . In other 
words, it is only after the peer receives one or more locations from the RNS server that 
the peer forwards the request to a selected location or locations from among the 
location(s) returned by the RNS server. Thus, in FIG. 4, ref. 440 and paragraph [0081], 
Teodosiu does not teach that the RNS server forwards the query message to the 
determined resource instance . In fact, nowhere does Teodosiu describe a resolver node 
that forwards a query message to a determined resource instance. 
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Thus, for at least the reasons presented above, the rejection of claim 1 is not 
supported by the cited prior art and removal thereof is respectfully requested. Similar 
remarks as those above regarding claim 1 also apply to claims 22, 41, 54, and 66. 

Regarding claim 2, contrary to the Examiner's assertion, Teodosiu fails to 
disclose a determined resource instance configured to send a response message in 
response to the query message to the peer node... sending the query message . Examiner 
cites Teodosiu paragraph [0081]. Note that paragraph [0081], as previously mentioned, 
describes that the peer (platform 370) waits... for a response from its home RNS server. 
If one or more locations are received, platform 370 selects one or more locations to try in 
460. The request is then forwarded as peer-to-peer traffic 320 directly to the selected 
location or locations in 425 . In other words, paragraph [0081] is describing the peer 
forwarding the request to the location (which was returned to the peer by the RNS server) 
of a resource, and does not describe a resource instance sending a response message to 
the peer. 

Thus, for at least the reasons presented above, the rejection of claim 2 is not 
supported by the cited prior art and removal thereof is respectfully requested. Similar 
remarks as those above regarding claim 1 also apply to claims 23, 42, 55, and 67. 

Regarding claim 4, contrary to the Examiner's assertion, Teodosiu fails to 
disclose a resource (configured to) implement one or more resource handlers wherein 
each of the one or more resource handlers is operable to receive the query message and 
generate a response message in response to the query message: (and wherein the resource 
is further configured to) register the one or more resource handlers with the resolver 
node . The examiner cites paragraph [0031], and indicates that, in that paragraph, 
Teodosiu teaches wherein the handlers are handling the resource peer location lookup 
where each peer in the realm contains a unique identifier . Note that the resource handlers 
described in the cited claims and elsewhere in the application do not handle resource peer 
location lookup; that task is performed by the resolver node, with which the resource 
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handlers are registered. Instead, the resource handlers are configured to receive query 
messages for associated resources and generate response messages to the received query 
messages. In addition, the Examiner indicates that, in paragraph [0031], Teodosiu 
teacfies that the resource is configured to register the one or more resource handlers with 
the resolver node . In paragraph [0031], Teodosiu teaches that peers register with a 
registrar, in the process of which each peer is assigned a unique identifier and is 
registered with a RNS server. Nowhere does Teodosiu teach that resources are 
configured to register resource handlers for the resources with a resolver node; 

Thus, for at least the reasons presented above, the rejection of claim 4 is not 
supported by the cited prior art and removal thereof is respectfully requested. Similar 
remarks as those above regarding claim 1 also apply to claims 25, 43, 56, and 68. 

Regarding claim 10, contrary to the Examiner's assertion, Teodosiu fails to 
disclose wherein the resolver node is a peer node of the plurality of peer nodes. Teodosiu 
discloses a RNS server that is configured to locate resources for peers and to return the 
location(s) of the resources to the peers, and nowhere teaches that the RNS server(s) is a 
peer node, or that a peer node serves as a "resolver node". This is clearly disclosed in 
Teodosiu in FIG. 1, and in paragraph [0030] describing FIG. 1: 

FIG. 1 illustrates one embodiment of the inventive peer-to-peer network. 
In the illustrated embodiment, peer-to-peer realm 150 (hereafter simply 
called "realm") includes registrar 110, gate server 120, a number of RNS 
servers 130. and a number of peers 140. Peers 140 store, or otherwise 
make available, peer resources (not shown). Registrar 110, RNS servers 
130, and gate server 120 together provide a locator and access service for 
tracking, locating, and accessing the peer resources published in the realm. 

The Examiner cites FIG. 3, and states wherein the components in the P2P 
platform not only serves peers with location findings and but also request peers for 
resources . Note first that FIG. 3 illustrates a peer 140 from FIG. 1, and not an RNS 
server 130, as is clearly indicated in paragraph [0070]: FIG. 3 illustrates one embodiment 
of a peer 140 from FIG. 1 in more detail . As previously described, it is the RNS server 
130 that performs resource locations, and not any of peers 140. Further, in describing 
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FIG. 3, in paragraph [0072], Teodosiu teaches that peer platform 370 includes resource 
locator interface 330 to interface directly with locator services. Teodosiu does not teach 
that peer platform 370 serves peers with location findings . Instead, Teodosiu teaches that 
peer platform 370 includes a resource locator interface that interfaces with locator 
services; the locator services (i.e., RNS server(s), which are not peers) are responsible for 
locating resources. 

Thus, for at least the reasons presented above, the rejection of claim 10 is not 
supported by the cited prior art and removal thereof is respectfully requested. Similar 
remarks as those above regarding claim 1 also apply to claim 31. 

Applicants further note that the rejection is improper because the Examiner 
has not shown that Teodosiu qualifies as a prior art reference. More specifically, 
Teodosiu is a published U.S. patent application that was filed on Sep. 13, 2001, after 
Applicants' priority date of Jan. 22, 2001. Teodosiu does claim the benefit of two 
provisional applications both filed Nov. 22, 2000. However, the Nov. 22, 2000 filing 
date can only be used as Teodosiu's 35 U.S.C. § 102(e) prior art date for the subject 
matter that is common to both the published application and the provisional application. 
Since it is common practice for a later filed utility application to include more or different 
subject matter than its earlier provisional application, it is unclear whether the material in 
Teodosiu relied upon by the Examiner was actually present in Teodosiu's provisional 
application. In fact, examination of Teodosiu's two provisional applications shows that 
they vary greatly from Teodosiu's published utility application. It is not apparent that the 
subject matter on which the Examiner is relying on to reject Applicants' claims is also 
present in one of Teodosiu's provisional applications. Unless the Examiner can make 
this showing, the rejection is improper. See, In re Wertheim, 209 USPQ 554 (CCPA 
1981). 

Moreover, Teodosiu's published application is not entitled to the Nov. 22, 2000 
date as a section 102(e) prior art date unless at least one claim of Teodosiu's published 
application is supported (under 35 U.S.C. § 1 12) in the provisional application. Under 35 
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U.S.C. 119(e)(1), a published utility application is not entitled to its provisional 
application's filing date as a prior art date unless at least one claim of the published utility 
application is supported (per 35 U.S.C. § 112) in the provisional application. The 
rejection is improper unless the Examiner can show that Teodosiu's published application 
has the necessary claim support in the provisional application to be entitled to the 
provisional application's filing date as its § 102(e) prior art date. See also M.P.E.P. § 
2136.03(IV). 

The Examiner has the burden of proof to produce the factual basis for the 
rejection. In re Warner, 154 USPQ 173, 177 (C.C.P.A. 1967), cert, denied, 389 U.S. 
1057 (1968). Since the Examiner has not proven that both of the above requirements 
have been met for Teodosiu's teachings to qualify as prior art, the Examiner has not met 
this burden of proof and the rejection is improper. 

Section 103(a) Rejection ; 

The Office Action rejected claims 12, 15, 33 and 36 under 35 U.S.C. § 103(a) as 
being unpatentable over Teodosiu in view of Gilmour et al. (U.S. Publication 
2004/0068477) (hereinafter "Gilmour"), claims 13, 16, 34 and 37 as being unpatentable 
over Teodosiu in view of London (U.S. Patent 6,061,734), claims 18, 19, 39, 40, 50, 51, 
62, 63, 69 and 70 as being unpatentable over Teodosiu in view of Jindal et al. (U.S. 
Patent 6,324,580) (hereinafter "Jindal"), and claims 20, 21, 53, 65 and 71 as being 
unpatentable over Teodosiu in view of Bhagwat et al. (U.S. Patent 5,941,988) 
(hereinafter "Bhagwat"). Applicants respectfully traverse these rejections for at least the 
reasons presented above regarding the independent claims. Accordingly, removal of the 
35 U.S.C. § 103(a) rejections is respectfully requested. 

In regard to the rejections under both § 102(e) and § 103(a), Applicants also assert 
that numerous ones of the dependent claims recite further distinctions over the cited art. 
However, since the rejections have been shown to be unsupported for the independent 
claims, a further discussion of the dependent claims is not necessary at this time. 
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CONCLUSION 



Applicants submit the application is in condition for allowance, and*notice to that 
effect is respectfully requested. 

If any extension of time (under 37 C.F.R. § 1.136) is necessary to prevent the 
above referenced application from becoming abandoned, Applicants hereby petition for 
such extension. If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5681- 
07300/RCK. 

Also enclosed herewith are the following items: 
Return Receipt Postcard 

□ Petition for Extension of Time 

□ Notice of Change of Address 

□ Fee Authorization Form authorizing a deposit account debit in the amount of $ 
for fees ( ). 

□ Other: 



Respectfully submitted, 




Reg. No. 39,255 

ATTORNEY FOR APPLICANT(S) 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: June 22, 2005 
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